Futuristic design review in the construction industry

Many researchers have already demonstrated the benefits of enhancing collaboration in the construction industry and the role of IT as a facilitator of inter-enterprise communications is also well accepted. However, the construction companies are slow to implement these best practices because they do not address the real needs of the workers. This paper goes further than previous approaches by describing not only the technological requirements that permit cooperation in a construction project, but also the human factors that need to be addressed in order to achieve effective collaboration. These requirements are illustrated by a futuristic scenario which shows how state-of-the-art human-centric technologies could support the interactions of co-workers during a design review meeting. This scenario will be used as a demonstrator of the CoSpaces platform for collaboration, and some of the technologies developed for its implementation are shortly introduced here. the life cycle can avoid excessive exponential cost and time overruns (Bassanino et al. 2001, Blyth & Worthington 2001). Secondly, unplanned meetings might be necessary to address urgent issues. These reactionary meetings are more likely to happen at a later stage of the project when a rapid decision is required to avoid incurring delay. In addition, this decision often has to take into consideration the work of other stakeholders in order to avoid prolongation of the problem. Reactionary (unplanned) meetings can be partially avoided by improving the efficiency of decisional gates. To do so, the number of stakeholders viewpoints considered during these meetings should be maximised, and the system should support both formal and informal inter-disciplinary communications. Social relationships are mainly important during the initial phase of a project as they enable the participants to share a common understanding by enhancing in depth discussions. Indeed, it has been demonstrated that the efficiency of knowledge acquisition depends on previous experience (Anderson 1977). Co-workers must therefore understand each others‟ backgrounds before being able to build a shared understanding of a problem or a project. A frequent issue of collaborative meetings is that decisions have to be postponed to the next meeting due to information not being readily available to the meeting representative of the particular competence. The stakeholders therefore have to wait for retrieval of further information until the next meeting. Due to the limited availability of these stakeholders, this can result in significant delays or in the reduction of decisional quality from missing viewpoints. If information and functional questions could be asked and answers delivered during the meeting decisions could be made more efficiently and speedily, with a fuller understanding of the context of the discussion. The technology can be a way to link the meeting attendants to their remote colleagues, therefore addressing these issues. In addition, the traditional nature of the construction industry is extremely „document-centric‟ with project information being captured predominately in documents. Although project information may be produced in an electronic form, in essence it is distributed among the various multi-disciplinary teams involved in the project as documents. Such document-centric nature of the industry and insufficient integration and interoperability between software applications has resulted in significant barriers to communication between the various stakeholders, which in turn affected the efficiency and performance of the industry. Gallaher et al. (2004) indicated that $15.8 billion was lost annually in the U.S. Capital Facilities Industry due to the lack of interoperability. It is therefore clear that the construction industry could greatly benefit from increased collaborative practices. The above examples also show the need for technology-intensive workspaces in order to address issues such as interoperability, availability and reactivity. In addition, communication between coworkers from several disciplines could be enhanced by human-centric technologies such as the ones described in the following scenario. 3 FUTURISTIC DESIGN REVIEW SCENARIO The realistic futuristic scenario hereafter illustrates the use of new technologies to improve co-located meetings by considering the above issues and requirements. The expected benefits of such a scenario is that fewer meetings are needed due to incomplete agreements, fewer problems have to be solved and it is possible to redesign as well as test alternative solutions during the meeting. This accelerates the overall project and increases the collaborators availability in case their expertise is required for minor issues. 3.1 Presentation of the scenario The scenario starts when a space that was originally designed to be a toilet for disabled people is reduced in floor area. This is due to the addition of a separate installation shaft for supply and ventilation system in that space in order to respond to new requirements for fire protection and safety. As a consequence, the toilet has to be redesigned, but must include similar elements as previously planned: a close-coupled WC, a basin, a bath tub, a wall hung cupboard and a window (Figure 1). The stakeholders are identified and invited to attend a meeting at the architectural company where the new proposed design must be presented and validated by a range of people with very different perspectives, interests and concerns. The identified stakeholders are presented in Figure 2. Figure 1. Possible setting for the toilet‟s elements. Figure 2. The meeting participants. 3.2 The preparation of the meeting Gary is the project manager for the construction of a building that includes a few apartments for disabled people. In order to solve the issue presented above, he connects to the CoSpaces website, which provides some tools to quickly set up collaborative meetings. This website has been used during the overall project to organise meetings, so that all the stakeholders are already known by the system, and they all have a username and password. The website also contains information about the Virtual Organisation such as a shared calendar or a description of the roles and profiles of the stakeholders. Gary accesses information about the stakeholders and their availability in order to facilitate the organisation of the meeting. He selects the participants as well as few dates when everyone seems to be available. When it is done the system sends an email to all the collaborators and asks for a confirmation of attendance. Gary can carry on with other work and wait for the answers. Simon is a municipal architect who has been involved in the project since its start. He realises that he already has other appointments on that dates that he did not indicate on the shared calendar. He then decides to send one of his colleagues, Trevor, to represent him during the meeting. Trevor has been previously involved in the project, and his profile is already known by the CoSpaces website. In addition, Simon contacts a disabled person called Wayne, so that he can test the design during the meeting and share his experience with the other participants. His profile is added to the website, as well as some description of his disability, so that the interface can be adapted to his needs. Finally, Simon replaces himself by Trevor in the participants list and he adds Wayne and a description of his role during the meeting. When he confirms their participation, a distribution list is automatically updated to facilitate later communications. The same day, all the stakeholders have confirmed their availability and Gary is able to finalise the date. Simultaneously, the CoSpaces website creates a shared workspace automatically, so that participants can start sharing information and documents about the meeting. Part of this information forms the context of the meeting, such as the date, time, venue, objectives, participants and links with previous meetings. All these can be used to classify the meeting and allow for later references. They also permit to describe the context of the decision in order to better understand the outcome of the meeting. Following the confirmation of the meeting, Gary produces a draft agenda and sends it through the shared workspace which distributes it automatically. A room is also booked according to the number of participants and to the required technologies. This booking can be adjusted to match new requests from the participants. Alex is the architect of the project. Like every participants, he receives an email with a link to the shared workspace. There, he can add documents that he finds interesting for the meeting. Some of the documents he selects are available in the project data space, like the 3D model of the toilet. By default, these documents come with similar access rights during the meeting as they have during the rest of the project. In addition, the context-aware feature of the collaborative system indicates that he has recently taken part in a very similar meeting during another project. He decides to select a 3D model of that project, but restricts the access rights to his own use only, so that he will be able to use his past experience during the meeting. Figure 3. 3D representation of the toilets.